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Address Specification Syntax for Network Mail 
Experience with processing mail on the Arpanet has pointed up many 
addressing issues, including: 
1. People’s names are not the same as their addresses; 


2. Mailing lists can get quite long; 


3. To allow responding, messages often need to carry all of their 
mailing list with them; 


4. It would be very useful to be able to send mail to files other 
than the person’s primary mailbox. 


The current mail syntax, specified in RFC 680, does not provide a 
convenient mechanism for distinguishing between a person’s name and 
their mailing address. In cases of shared directories, the ATTN: clause 
is marginally adequate; however it is completely inappropriate for 
single-user mailboxes in which the address specification is simply 
cryptic. CMU’s identification tags are good examples of this problem, 
since they tend to appear to be random character sequences; the use of 
initials as tags also points up the problem. If you doubt the 
referential ambiguity of addresses, then try to use only the information 
presented, rather than random personal knowledge, to discern who 
Micro@ISI, JFH@ISI, or Greep@ISD are. By having a formal syntax for 
separately specifying names and addresses, mail display software can 
printout out name lists which only contain human names...makes things 
friendlier. 


The problem with long mailing lists is that, if included in the text of 
a message, they often are longer than the main part of the message. 
Group names are allowed in address fields primarily to circumvent this 
problem. However the advent of semi-automated message answering, in 
which a receiver’s message system prepares address lists for reply 
messages by copying appropriate fields from the original message, makes 
the current mechanism deficient: having the group name means that the 
receiver does not have the names/addresses of the members of the group. 
A convention is generally followed, now, which has the group name be a 
pathname to the file containing the list. Though facilitative, this 
does not represent an adequate solution. 


And lastly is the issue of multiple mailboxes for a single user. This 
feature is probably has the largest potential for teleconferencing 
applications, with messages for an on-going discussion automatically 
placed into a separate mailbox. In the case of shared directories, this 
mechanism also would allow easy channeling into each person’s own 
mailbox. 


With these needs in mind, and until a more robust mail syntax and 
protocol is specified, the following general syntax is proposed to 
augment the existing syntax specified in RFC 680, for address fields 
specified by the user: 


Name: (Person (User-Id(Mailbox) at Host),...),; 
Where 
"Name" is the name of the mailing list; "Person" presumably is 


the name of the person receiving the mail; 


"User-Id" is their online reference name (usually their signon 
directory); 


"Mailbox" is a a secondary mailbox/file; 


and the rest conforms to RFC 680, although "@" may be used in 
place of " at " in the specification. 


Parentheses may be replaced by other bracketing pairs ([], {}, <>). 
Quotation marks must be used any time the string contains ambiquating 
characters, such as space or parentheses. The brackets after Name are 
used to request exclusion of the address list from the message, instead 
using text which gives the pathname to the source of the list. 


The formal syntax for address specification, within network mail 
actually sent, is included in the next section. 


Not all of a specification is required, so perhaps some examples will 
clarify things:. 


A normal specification, as used currently: Walker at ISI 
A named list, to be carried with the message, with the last 
address not a member of the list: List:Walker at 


ISI, greep@rand-isd;Action@ISI 


A named list, NOT to be carried with the message; the list 
contents will be replaced with a text string indicating the source 


of the list -- not very useful if the list is typed in by the 
user, rather than pulled from a file; therefore 
List: (Walker@ISI,greep at rand); Action at ISi will be changed to 


appear in the message as List: ("/rnd/dcrocker/mail.list"); Action 
at ISI 
A list with personal names. separate from addresses: "Steve 


Walker"[Walker at ISI], Bob<rha@isd> 


A teleconferencing address list: 
Talkers:"Dave C"(DCrocker(TC.msg) @isi),...; 


-2- 


Formal Specification 


The following modified BNF is to serve as a direct 
addition/replacement for specifications within RFC 680. The fields 
eliminated from the existing specification are: <addressee item>, 
<address list>, <addressee>, <mailbox>, <host spec>, <attention spec>. 
<user list>, <mailbox group>, <group numbers>, and <mailbox list>. 


<Attention spec> can be performed through use of the person’s name 
and secondary file specification. Also, <Sender> should be modified 
to be:: 

Sender = "SENDER: " Individual 


And the added fields are: 


Address-Field = Address-List / Address-List ,,:, 
Address-Field 


Address-List = Individual-List / Group-List 


Group-List = Group-Name Group-—Members 


Group-—Name / Name ":" 
Group-Members = Individual-List / L-Bracket Pathname 
R-Bracket 


Pathname = {A Name which can at least provide a 
human with enough information to find 
the file containing the Group-List} 


Individual-List = Individual / Individual 


Individual-List 
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Individual = Mailbox / Name L-Bracket Mailbox 


R-Bracket 
L-Bracket = " (" / " [" / " { " / wen 
R-Bracket = ") " / "] " / " } " / wou 


Mailbox = Id Secondary-File At Host 


Id = Name 
At = "™" atom / wan 
Host = {An acceptable host name} 


Secondary-File = / L-Bracket Filename R-Bracket 
Filename = Name 


Name = {An Ascii string without carriage 
return, line feed, space, ’"’, ",", 

";", or any L-Bracket or R-Bracket} / 
‘wr {An Ascii string with any double 
quotation marks doubled} ’"’ 


The particular L-Bracket and R-Bracket characters used must match 
each other. The requirement for quotation marks has been made more 
severe than absolutely necessary in order to simplify software 
requirments. Note also that the above specified syntax is for 
inter-entity communications and is not necessarily indicative of what 


the user types. 


